<h2>Play with this demo</h2>
<p>
In this Activity, you can : 
<ul>
  <li> start a Loader observe the result : getting a list of tweets about android ;
  <li> cancel a started Loader ;
  <li> start a Loader, rotate the device and observe that UI is updated as expected (result is cached by Loaders);
  <li> after you rotated the device, the loader is still complete : starting it again will get you instantly with the 
  result (cached result is returned) and you must cancel the loader to update the tweets.
  <li> rotate the device as much as you want, even during loading, loaders are robust; 
  <li> observe no more memory leak, you can start as many Loaders as you want.
</ul>
</p>

<h2>Loader for REST request. </h2>

<p>
This Activity uses a Loader to get the list of tweets related to Android. 
</p>

<h3>a Proof of Concepts </h3>

<p>
It is based on an idea developed by Neil Goodmann in its article : 
Modern Techniques For Implementing REST Clients On Android 4.0 And below 
(<a href="http://neilgoodman.net/2011/12/26/modern-techniques-for-implementing-rest-clients-on-android-4-0-and-below-part-1/">part 1</a> and 
 <a href="http://neilgoodman.net/2011/12/26/modern-techniques-for-implementing-rest-clients-on-android-4-0-and-below-part-2/">part 2</a>). Neil Goodmann
 wrote a complete tutorial and made the source code available <a href="https://github.com/posco2k8/rest_loader_tutorial">on a Git Hub repo</a>.
 We look forward to re-implement the loader using a more standard library for executing rest requests : 
 <a href="http://www.springsource.org/spring-android">the spring android RestTemlate</a>, but current RestLoader proposed by Neil Goodmann is mature enough
 for this demo.
</p>

<p>
Although the technique doesn't seem to be very well know from Android developers, it's actually a neat solution : it works perfectly and 
offers a robust approach to asynchronous job execution, without any kind of memory issue.
</p>

<h3>Progress and loaders </h3>
<p>
On this demo activity, you can't observe the progress of the Loader's job. But we believe this should be possible.
</p>

<h3>Cancelling the request </h3>
<p>
Loaders can be cancelled easily and this applies to this example as well.
Note that, once REST request is sent, it can't be aborted. We believe this limitation could be leveraged as well.
</p>

<h3>Networking operations</h3>
<p>
Nevertheless, when it comes to networking operations, using Loaders has several drawbacks and limitations that we will summarize as follow : 
<ul>
  <li> Loaders handle Activity life cycle pretty well. If you start the request, get the result and rotate the device, you still get the result displayed but</li>
  <li> If you click on the start button and rotate the device before getting the result then the request is executed but previous response is lost, cache 
  is cleared before restarting the loader.</li>
  <li> Moreover the result is not stored on disk. So, if you leave this activity and come back, you will have lost the result of the REST request. </li>
  <li> If you click twice on the start button, the second click has no effect. If you want to refresh the results, you must first cancel the Loader
       and then start it again. This life cycle is rather counterintuitive and illustrates how far Loaders' design is from common networking requirements. 
</ul>
</p>

<hr>
We now propose a new approach for asynchronous network operations, using RoboSpice. Next tutorial is the exact same application, but <em>spiced</em>. As you will 
see RoboSpice allows to go far beyond those limitations.